Part 44: Disability Corner: Screenreaders

Disability Corner: Screenreaders

The company I work for has a thing about accessibility. For those of you unfamiliar with the concept, accessibility refers to making things, well, accessible to disabled people; it covers everything from physical elements like ramps for wheelchair users to limiting colorblindness-unfriendly color-coding on screens. It is very proud of how much time, effort, and money it’s pouring into its People with Disabilities program, and management just pledged to make its entire web presence meet its digital accessibility standards by the end of the year… Which is a very nice dream, and good on them for trying, at least. That means mandatory accessibility implementation training in the Technology department (where I work), which brought me into contact with screenreaders for the first time.

Screenreaders are programs that read computer screens out loud. You’ve probably seen the term here are there, especially earlier in the thread when I went back and made sure the first few updates included all the text in the update instead of leaving some of it trapped in images. I thought originally they were made for blind folks or those with low vision, but it turns out I’m wrong – screenreaders usually work for Neurodiverse people of various stripes, too. Like, a couple years ago a good friend of mine talked to me about how ADHD made reading large blocks of text impossible for them. This wasn’t something they liked, they mourned their inability to read novels or textbooks, but their brain would do that involuntary attention divergence thing so familiar to ADHDers every couple sentences and the text would dissolve into incoherence after a couple minutes. They do a lot better with spoken information, though, which is where a screenreader would come in; it can move through text bit by bit in ways they could customize to match their reading style, making that stuff possible for them to consume. Had I known this was a thing then, I would have brought it up. Granted, screenreaders don’t work for everybody, and they eventually got prescribed Adderall by their psychiatrist and marveled at how well it fixed the issue but the nature of psychiatric medication is another disability corner for another time.

Anyway, screenreaders come in several varieties with different costs, capabilities, and platforms, some of which date back quite a ways; I found an article on talking terminals from 1982, and even back then the technology and market were both developed enough to support three different brands of machine. Those machines’ modern descendents come in a bunch of flavors, like handheld e-readers that convert epubs into impromptu audiobooks, but from what I can tell most people use screenreading programs. These days, every major operating system comes with screenreaders of… Variable quality, so most people seem to use NVDA or JAWS instead, two programs built for screenreading from the ground up. They seem to be more complex than the built-in options, but also, you know, actually flexible enough to use.

Screenreaders, whatever the specifics, function by reading formatting as much as text. Yeah, they do obviously read text, but they also detect headings, links, and objects and give you ways to interact with them. I’m not just talking about webpages here; they can read Microsoft Office documents of various kinds, too, and even take basic dictation sometimes. But they aren’t perfect. You know how I said they read formatting? They can only read stuff that uses correct formatting; if something communicates information visually, it may as well be blank space. Like, in a Word document, if you want a screenreader to understand where sections and subsections fall, you have to use the Formatting tab options instead of just manually typing things in with underlines and such. If you do, screen readers can jump between sections; if you don’t, they just read those headers as more text. Granted, you should probably be using Formatting headers for long documents anyway because they let you navigate through the documents in the Headings sidebar and make a table of contents, but I’ve worked in tech long enough to realize just how many people use dumb workarounds. Likewise, most kinds of tables may as well be impenetrable: they MIGHT be able to read one column before moving on. Online, they can’t handle a lot of pop ups or visual elements, or the kind of sloppy coding that doesn’t correctly name objects on the assumption that the user won’t care.

But for all that, screenreaders are powerful programs, and accessible design is a lot easier than you might assume. They can read properly formatted PowerPoint, Excel, and Word documents well enough to make them useable for their, well, users, guiding them through formatting options and reading their typing back to them – and these formatting options are not that complex, you can access everything you’ll need on the default ribbon. They read web pages by going into the HTML, so as long as everything’s correctly laid out in there, they can extract more than enough to make the page usable. You know how you can use tab to cycle through selectable objects, like how they cheated at flash games back in the day? That’s an accessibility feature, and it’s something screenreaders excel at. While some kinds of tables just don’t work, they can read stuff like calendars just fine, and as long as objects have names hidden in certain ways in the code, they can read them out like anything else.

Which is why I’m posting this now instead of when we get to Lilly (other than the fact that I don’t think she ever uses any kind of screenreader). See, Something Awful posts don’t actually use HTML; they use a simpler derivate called BBCode specifically designed for forums. It’s much simpler, easier to learn, and interfaces with plaintext a lot better on the user end. I’m very good with BBCode; I can’t do shit with HTML. Unfortunately, BBCode is a lot more limited in its scope, and SA’s version is more limited than most. Most importantly for LPs, screenreaders read images by checking for something called alternate text, basically descriptions of images appended to their code; I understand it started out as a way programmers could see what an image was without making it display, but since it usually lays out everything important in the image, screenreaders target it. If they don’t see alt text, they usually skip the image entirely. When I started writing this disability corner, SA didn’t support alt text at all. Screenshots, portraits, the smilies SA’s so famous for, all that’s invisible to a screenreader. It meant this LP is fundamentally screenreader hostile given how I’m formatting dialogue. I took out a ticket on this in the tech support forum to deal with this, but I despaired when I never got a reply.

And then I did! Turns out alt text and other accessibility features have been in the pipeline for a while. And now, smilies have alt text ! That doesn’t remove this LP’s accessibility issues, though. I’ve been hoping I could keep the standard portrait-text dialogue format most screenshot LPs use and just sub in new portraits with alt text when that gets implemented; I have a gigantic macro that runs through every update and ads in portraits and music links when appropriate, and I could just run old updates through it after tweaking it to replace the old portraits. But I have no idea when that’ll get implemented. And beyond that, turns out screenreaders can’t detect text formatting, so the italics I’ve been using to differentiate my commentary and in game text in the updates just won’t cut it (the italics I’ve been using for emphasis aren’t as big a deal to me, but they probably don’t help anything on that end). I have no idea how to replace them, either. Maybe putting them in parentheses or brackets? I’m not going out of my way to implement a ramshackle solution when better ones might be on the way.

Which is where you guys come in. As always, I could use suggestions on boosting accessibility. If anyone here uses screen readers and would like me to do something to make this experience better, please let me know and I’ll get it done. I also invite screenreader users to point out what I got wrong; this is ultimately just a really high level survey of a complicated subject done by somebody with very little experience with it. I’d love to be proven wrong.